Adding code to analyze the siginificant wave heigh in GSI 3D Analysis (see issue #601) #614
Conversation
esp. for FV3-LAM model based DA, eg. RRFS-DA, RRFS-3DRTMA. (Also see the issue in EMC GSI github repository: #601 Adding I/O for Analysis of Significant Wave Height for 3DRTMA)
There was a problem hiding this comment.
A general comment:
I would suggest we drop the two interval variables: i_howv_in_data and i_howv_in_anav
Whether to read howv observations should be solely determined by user setting in the OBS_INPUT section of gsiparm.anl
Whether to read howv from first guess should be solely determined by user settings in the anavinfo file. If user wants howv but the first guess does not have this field, GSI should stop at this critical error.
|
@guoqing-noaa @TingLei-NOAA @hu5970 ,
I still incline to keep i_howv_in_anav and i_howv_in_data in current version of code to analyze howv in 3D GSI analysis. The explanation will be addressed in this comment.
Yes, I agree. It was indeed done by adding at least the following two lines in the "OBS_INPUT section of gsiparm.anl"
Yes, as you mentioned "determined by user settings in the anavinfo file", for this reason, the variable "i_howv_in_data" is introduced here. If howv is in anavinfo file, i_howv_in_data = 1, otherwise as 0. Then there are several places in the I/O subroutines, i_howv_in_data is used to set the guess bundle array ges_howv. As for "If user wants howv but the first guess does not have this field, GSI should stop at this critical error", yes and no. The variable "i_howv_in_data" was not introduced into analysis of howv in the beginning stage of code development. I made a test run, in that test run, there is howv in the anavinfo, and howv is also set in namelist, the obs file of howv are also copied, but there is NO howv in the firstguess file. Then I let GSI run. The interesting thing is that GSI did NOT crash (as you mentioned in another comment: in init_vars_ of setuphowv, if no firstguess, then GSI should stop), and GSI still ran with howv in cost function, in outer-loop and inner-loop of minimisation. I mean the essential part of GSI analysis was done, GSI was running almost to the end, then it just hung there until the wall-clock time limit was reached and the job was killed. Later I found that GSI was stuck in the step to output the analysis of "howv" into original firstguess file but actually howv was not in firstguess. But GSI did not give out any error message and information, just hung up there. Thanks, |
|
Thanks for your efforts including howv in the 3D regional applications and thanks for lots of great discussions. I now get a better understanding of your considerations. And my thoughts are updated as follows: The behavior of howv in 3DDA is different that of t2m/q2m. It requires adding new entries to "met_guess", "state_vector" and "control_vector" in anavinfo. So the behavior of howv is similar as, for example, aerosol DA. In this sense, I would suggest we add a top level parameter in gsiparm.anl to control whether and how to do howv in 3DDA. We may add "l_howv_3DDA" to turn on/off. Or we may add "i_howv_3DDA" with 0= no howv in 3D DA; 1= howv in 3DDA with default settings; 2=howv in 3DDA with static BE scaled in a hybrid 3DEnVAR setting. I would hope this will simplify the overall logic and avoid the use of two internal flags "i_howv_in_anav" and "i_howv_in_data" As to "corp_howv" and "hwllp_howv", since you already developed these new options, we can keep them if you like. I think it will be a good addition. In this situation, we may want to introduce a new namelist section, such as "&HOWV_3DDA" (similar to, for example, &CHEM), to host all howv_3DDA related parameters (such as i_howv_3DDA, corp_howv, hwllp_howv, etc). However, I think it is also fine to put all those new parameters in the &RAPIDREFRESH_CLDSURF namelist section. Thanks! |
|
Hi Guoqing,
(I cannot find Manuel's github name on github, so to include Manuel in this
discussion loop, I have to reply to this email directly, instead of making
a comment reply in the PR <#614> #614
<#614>.)
As you mentioned that "The behavior of howv in 3DDA is different that of
t2m/q2m. It requires adding new entries to "met_guess", "state_vector" and
"control_vector" in anavinfo.". Yes, I agree with you.
As your suggestion to "add a top level parameter, l_howv_3DDA or
i_howv_3DDA, in namelist file gsiparm.anl" to control whether and how to
down in 3DDA, I remember that in the beginning of my work on howv in 3DDA,
Manuel suggested me to just set "howv" in anavinfo to trigger the analysis
of howv in GSI, instead of using namelist option to turn it on. And this is
also how howv is analyzed in current 2DRTMA. And even if using this
namelist option, e.g., i_howv_3DDA=1, to turn on analysis of howv, but it
still could not fix the problem that the howv is accidentally missing in
the firstguess (e.g., due to crash of upstream WW3 model), it is still
necessary to detect the existence of howv in firstguess and mark the
existence with an internal flag, e.g., "i_howv_in_data=1", and as I
mentioned in previous comment, this is also helpful to avoid the potential
hung-up issue in GSI run.
I agree with you that the two current internal variables, "i_howv_in_anav"
and "i_howv_in_data", might be too much. So following your idea (Thank you,
Guoqing!), those two internal flags could be combined into one flga as
"i_howv_3dda":
i_howv_3dda = -1 (howv-off) : no analysis of howv in 3D analysis. This is
the default and initialised as default inside GSI;
i_howv_3dda = 0 (howv-standby) : if variable name "howv" is found in
anavinfo file, then set it to be 0;
i_howv_3dda = 1 (howv-on) : if i_howv_3dda=0 (standby since it is in
anavinfo), then it would check the existence of howv in firstguess. If it
is available in firstguess, then set i_howv_3dda=1, this will turn on the
real analysis of howv in 3D analysis, such as reading firstguess of howv,
switching on the usage of howv obs in setuphowv, and the final output of
the analysis of howv into original firstguess file, etc.
I hope this could be a simple solution to this discussion.
As for "corp_howv" and "hwllp_howv", Manuel also mentioned that the two
static binary files should be better, just as used in 2DRTMA for analysis
of howv. Because I do not have these two files for 3D analysis yet, I
introduced these two namelist options for users to control them in
namelist. When I set up the two static BE files for howv, then these two
namelist options "corp_howv" and "hwllp_howv" could be cleaned off by a
minor patch to the code.
I am going to modify the code based on the review
comments/suggestions/discussions from you and Ting, then re-submit the new
commit to this same PR #614 <#614> for
the next round of your peer-review!
Thank you very much, Guoqing and Ting, for your very inspiring and valuable
comments/suggestions!
…-Gang
On Thu, Aug 31, 2023 at 1:17 PM Guoqing Ge ***@***.***> wrote:
@GangZhao-NOAA <https://github.com/GangZhao-NOAA>
Thanks for your efforts including howv in the 3D regional applications and
thanks for lots of great discussions. I now get a better understanding of
your considerations. And my thoughts are updated as follows:
The behavior of howv in 3DDA is different that of t2m/q2m. It requires
adding new entries to "met_guess", "state_vector" and "control_vector" in
anavinfo. So the behavior of howv is similar as, for example, aerosol DA.
In this sense, I would suggest we add a top level parameter in gsiparm.anl
to control whether and how to do howv in 3DDA. We may add "l_howv_3DDA" to
turn on/off. Or we may add "i_howv_3DDA" with 0= no howv in 3D DA; 1= howv
in 3DDA with default settings; 2=howv in 3DDA with static BE scaled in a
hybrid 3DEnVAR setting. I would hope this will simplify the overall logic
and avoid the use of two internal flags "i_howv_in_anav" and
"i_howv_in_data"
As to "corp_howv" and "hwllp_howv", since you already developed these new
options, we can keep them if you like. I think it will be a good addition.
In this situation, we may want to introduce a new namelist section, such as
"&HOWV_3DDA" (similar to, for example, &CHEM), to host all howv_3DDA
related parameters (such as i_howv_3DDA, corp_howv, hwllp_howv, etc).
However, I think it is also fine to put all those new parameters in the
&RAPIDREFRESH_CLDSURF namelist section. Thanks!
—
Reply to this email directly, view it on GitHub
<#614 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMWMXU5BG7JXVENA3ISERBTXYDBKVANCNFSM6AAAAAA35RZB5M>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi @GangZhao-NOAA ,
Thanks a lot for more discussions and I got more details you have considered. I think continued discussions do improve our understanding of this task.
Manuel,
It would be great if you could set up your Github account and get notified about RTMA-related Pull requests, including those in the ufs-srweather-app and regional_workflow, etc.
Gang,
For your proposed (-1,0,1) options for i_howv_3DDA, I have a concern that although we can take some time to learn and adapt to this combination, it is not intuitive. One may naturally think i_howv_3DDA=0 means NO how in 3DDA.
Here are my updated thoughts:
I understood the original choice to use anavinfo to control whether to read in howv from the first guess at that time. However, I also think things are changed when the task evolves. We want to keep 2D-RTMA intact while adding howv in 3D applications. Based on only howv in anavinfo, we don't know whether it is for 2D-RTMA or 3D applications without other supplementary
information. Adding a top-level parameter such as i_howv_3DDA will make this more explicit and intuitive.
It is lucky that adding howv in 3D apps only requires reading one more guess field. If more guess fields are required, a top-level parameter may be a must (such as the situation of laeroana_fv3smoke).
It is a valid concern and good consideration that missing howv in the FG may break the 3DRTMA process and prevent other important weather analyses from being delivered.
However, we can prevent this from happening at the workflow level. If there is no howv background available, we can simply set i_howv_3DDA to 0 in the workflow.
At the GSI level, inside subroutine gsi_fv3ncdf2d_read, if nf90_inq_varid(gfile_loc,'howv',id_howv) returns an error, then STOP GSI (i.e. users want to do howv analysis in 3DDA, however, howv background is not available, hence GSI stops and outputs warning messages).
|
(howv) in 3D analysis, based on feedbacks from code reviewers.
for significant wave height: 1) combine two variables i_howv_in_anav and i_howv_in_data into one variable i_howv_3dda 2) if howv is required in analyis (as set howv in anavinfo), but if howv is not available in firstguess, then stop GSI run. 3) removing the code which tunes the static BE of howv in hybrid envar run. So in hybrid run, user needs to set the corp_howv in namelist if desired. 4) cleaning some unnecessary comments
|
Guoqing,
As you mentioned, "This also opens a possibility that two different RTMA
experiments can share the same anavinfo files where the first one does HOWV
analysis and the second one doesn't. In this situation, we can simply set
i_howv_3dda=0 for the second one. This will greatly simplify the workflow."
Do you mean, no matter "analyzing HOWV or not", "howv" is ALWAYS added into
anavinfo file as DEFAULT for (3D)RTMA, just like the other regular
variables, like t/q/ps, etc.? Then whether analyze howv is controlled by
the namelist option "i_howv_in_3dda" only?
When define "i_howv_3dda" as namelist option, it would be initialized as 0
for default (no analysis of how), and since the read-in of anavinfo is
earlier than read-in of namelist, so I might still need to define a
internal variable "i_howv_in_anavinfo" to mark the existence of howv in
anavinfo.
By the way,in a case that there is no how in the anavinfo file and no
how in firstguess file, but the user accidentally or mistakenly set the
"i_howv_3dda=1" in namelist, then should GSI keep running WITHOUT analysis
of howv, or should GSI stop, since there is inconsistency between anavinfo
(missing howv) and namelist (i_howv_3dda=1) ?
Although this ("turning on the analysis of howv via an option in namelist,
not via howv in avavinfo") is different to the current configuration in the
operational (2D)RTMA system, it is OK with me. So as long as Manuel has no
comment on this, I can make it. Will let you know after the update and test
run.
Thanks,
-Gang
…On Sun, Sep 17, 2023 at 5:39 PM Guoqing Ge ***@***.***> wrote:
***@***.**** commented on this pull request.
Hi, @GangZhao-NOAA <https://github.com/GangZhao-NOAA> Thanks a lot for
making the changes!
------------------------------
In src/gsi/rapidrefresh_cldsurf_mod.f90
<#614 (comment)>:
> @@ -181,6 +185,18 @@ module rapidrefresh_cldsurf_mod
! = 2(clean Qg as in 1, and adjustment to the retrieved Qr/Qs/Qnr throughout the whole profile)
! = 3(similar to 2, but adjustment to Qr/Qs/Qnr only below maximum reflectivity level
! and where the dbz_obs is missing);
+! corp_howv - namelist real, static BE of howv (standard error deviation)
+! hwllp_howv - namelist real, static BE de-correlation length scale of howv
+! i_howv_in_3dda - integer, control the analysis of howv in 3D analysis (either var or hybrid)
+! = 0 (howv-off: default) : no analysis of howv in 3D analysis.
+! = 1 (howv-on) : if variable name "howv" is found in anavinfo,
+! set it to be 1 to turn on analysis of howv;
I would suggest making i_howv_in_3dda a tuning parameter in a GSI
namelist. If i_howv_in_3dda is set to 1, but users don't set anavinfo and
background howv files correctly, just let GSI stops/crashes as expected.
This also opens a possibility that two different RTMA experiments can
share the same anavinfo files where the first one does HOWV analysis and
the second one doesn't. In this situation, we can simply set i_howv_3dda=0
for the second one. This will greatly simplify the workflow.
------------------------------
In src/gsi/rapidrefresh_cldsurf_mod.f90
<#614 (comment)>:
> @@ -418,6 +444,19 @@ subroutine init_rapidrefresh_cldsurf
l_saturate_bkCloud= .true.
l_rtma3d = .false. ! turn configuration for rtma3d off
i_precip_vertical_check = 0 ! No check and adjustment to retrieved Qr/Qs/Qg (default)
+ corp_howv = 0.42_r_kind ! 0.42 meters (default)
+ hwllp_howv = 170000.0_r_kind ! 170,000.0 meters (170km as default for 3DRTMA, 50km is used in 2DRTMA)
+ i_howv_3dda = 0 ! no analysis of significant wave height (howv) in 3D analysis (default)
+
+!-- searching for speficif variable in state variable list (reading from anavinfo)
+ do i2=1,ns2d
+ if ( trim(svars2d(i2))=='howv' .or. trim(svars2d(i2))=='HOWV' ) then
+ i_howv_3dda = 1
+ if ( mype == 0 ) then
+ write(6,'(1x,A,1x,A8,1x,A,1x,I4)')"init_rapidrefresh_cldsurf: anavinfo svars2d (state variable): ",trim(adjustl(svars2d(i2))), " is found in anavinfo, set i_howv_3dda = ", i_howv_3dda
+ end if
+ end if
+ end do ! i2 : looping over 2-D anasv
If we make i_howv_in_3dda a tuning parameter in a GSI namelist, then we
don't need lines 451-459, 362-364 and 367.
------------------------------
In src/gsi/m_berror_stats_reg.f90
<#614 (comment)>:
> @@ -313,6 +313,7 @@ subroutine berror_read_wgt_reg(msig,mlat,corz,corp,hwll,hwllp,vz,rlsig,varq,qopt
use mpeu_util,only: getindex
use radiance_mod, only: icloud_cv,n_clouds_fwd,cloud_names_fwd
use chemmod, only: berror_fv3_cmaq_regional
+ use hybrid_ensemble_parameters, only: l_hyb_ens
remove line 316 as l_hyb_ens is not used anywhere in this updated version
of m_berror_stats_reg.f90
------------------------------
In src/gsi/gsi_rfv3io_mod.f90
<#614 (comment)>:
> @@ -1365,6 +1374,13 @@ subroutine read_fv3_netcdf_guess(fv3filenamegin)
call GSI_BundleGetPointer ( GSI_MetGuess_Bundle(it),'t2m',ges_t2m,istatus );ier=ier+istatus
if (ier/=0) call die(trim(myname),'cannot get pointers for t2m,ier=',ier)
endif
+
+!--- significant wave height (howv)
+ if ( i_howv_3dda == 1 ) then
+ call GSI_BundleGetPointer(GSI_MetGuess_Bundle(it),'howv',ges_howv,istatus ); ier=ier+istatus
+ if (ier/=0) call die(trim(myname),'cannot get pointers for howv, ier=',ier)
+ endif
comment: if we don't set howv correctly in anavinfo, GSI will die at line
1381
------------------------------
In src/gsi/gsi_rfv3io_mod.f90
<#614 (comment)>:
> @@ -1805,23 +1823,27 @@ subroutine gsi_fv3ncdf2d_read(fv3filenamegin,it,ges_z,ges_t2m,ges_q2m)
!
!$$$ end documentation block
use kinds, only: r_kind,i_kind
- use mpimod, only: ierror,mpi_comm_world,npe,mpi_rtype,mype
+ use mpimod, only: ierror,mpi_comm_world,npe,mpi_rtype,mype,mpi_itype
If we make i_howv_in_3dda a tuning parameter in a GSI namelist, then we
don't need mpi_itype.
------------------------------
In src/gsi/gsi_rfv3io_mod.f90
<#614 (comment)>:
> @@ -1835,6 +1857,9 @@ subroutine gsi_fv3ncdf2d_read(fv3filenamegin,it,ges_z,ges_t2m,ges_q2m)
integer(i_kind) kk,n,ns,j,ii,jj,mm1
character(len=:),allocatable :: sfcdata !='fv3_sfcdata'
character(len=:),allocatable :: dynvars !='fv3_dynvars'
+! for checking the existence of howv in firstguess file
+ integer(i_kind) id_howv, iret_howv
It looks like iret_howv can be safely replaced by iret.
—
Reply to this email directly, view it on GitHub
<#614 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMWMXU4UTQ5NLLLBPOJ2UYLX25UW7ANCNFSM6AAAAAA35RZB5M>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi @guoqing-noaa, @TingLei-NOAA @hu5970, @MatthewMorris-NOAA, @ManuelPondeca-NOAA @GangZhao-NOAA, Based on recent comments and suggestions from your code review, the code was modified and committed. Could you please take some time to review the updated code (commit #7888831)? The updates include clean-off of some unnecessary comments, not-used variables (iret_howv, l_hyb_ens, etc,) and one typo. There is one suggestion from Guoqing (@guoqing-noaa) -- "I would suggest making i_howv_in_3dda a tuning parameter in a GSI namelist". Manuel and I discussed on it, and Manuel pointed out that, if howv is added in anavinfo, esp. added as state vector and control vector, howv would be analyzed, even user sets "i_howv_3dda=0" and wants to turn it off. This would be a problem. Actually I did make out a version with "i_howv_3dda as top-level namelist option" following Guoqing's suggestion. The code is under branch "feature/3drtma_howv_nmls4gge" of my fork of GSI. And I did test it with "howv in anavinfo, howv in firstguess and howv in obs, but i_howv_3dda=0". It was expected that howv should not be analyzed, but actually it was included in the cost function and the minimization. Even it was NOT updated at final step (since i_howv_3dda=0), but it already influenced the minimization, then user would not get the exact results as expected. For the test results with version using "i_howv_3dda as namelist option", it could be found on Hera under "/scratch2/NCEPDEV/stmp1/Gang.Zhao/3drtma/rtma.v0.3.1_howv/stmp/2023071214/nmls4gge/": GSI running directory"anal_conv_gsi_yesdata_yesinfo_nonmls_4gge/": where you could see the anavinfo/convinfo/gsiparm.anl which have "howv" set up in them, but "i_howv_3dda=0" is set in gsiparm.anl. Then in the output log file "stdout", it could be found that as following: Obviously howv interferes with the computation of cost and gradient. So based on this and other considerations, we still suggest NOT set "i_howv_3dda" as a top-level namelist option (at least for now, it interested, we can revisit this topic by initiating another issue later). Thanks, -Gang |
|
The recently-updated code (commit #7888831) also passed the regression test (all 9 tasks) on Hera. Here are a brief test result: |
|
@GangZhao-NOAA Thanks a lot for your efforts improving the codes and has the productive discussions with @guoqing-noaa sorting out those questions, especially the last tricky one. I will approve it now. |
|
@TingLei-NOAA |
|
@guoqing-noaa @TingLei-NOAA @MatthewMorris-NOAA @hu5970 |
| iret = nf90_inq_varid(gfile_loc,'HOWV',id_howv) ! double check with name in uppercase | ||
| end if | ||
| if ( iret /= nf90_noerr ) then | ||
| i_howv_3dda = 0 ! howv does not exist in firstguess, then stop GSI run. |
There was a problem hiding this comment.
Line 1919 is not needed as GSI dies immediately.
There was a problem hiding this comment.
@guoqing-noaa
I agree, since GSI is going to abort immediately in this case.
My thought about keeping this line (i_howv_3dda = 0) here, is to mark this event (howv is NOT in firstguess) and can be used later, if in the future some users, eg. NCO, would not like to stop the running of GSI just just due to missing of howv, setting i_howv_3dda = 0 will be useful. And keeping this line here does no harm to the efficiency and accuracy of code.
Thank you!
Hi @GangZhao-NOAA , thanks a lot for the testing! Yes, you are right. I did not consider that we will also add howv in the control vector section. So, in this situation, we will need to have two different versions of the anavinfo files for howv runs and no-howv runs respectively. I think this PR should work without any running issues. This is just a personal preference. |
analysis of siginificant wave height.
|
Hi Guoqing,
Thank you for the suggestion!
As we discussed in previous comments, in current version the analysis of
howv in 3D GSI is controlled by setting howv in anavinfo file, not by
namelist option yet.
But I do agree that, using a namelist variable to control the analysis of
howv would be a good idea in the future version, esp. when the marine and
ocean analysis are added into RTMA in the near future. And it might be also
helpful when setting up the workflow with analysis of howv. We could
revisit this topic in the future version of analysis code for how.
Thanks again!
…-Gang
On Tue, Sep 26, 2023 at 2:03 PM Guoqing Ge ***@***.***> wrote:
Hi @guoqing-noaa <https://github.com/guoqing-noaa>, @TingLei-NOAA
<https://github.com/TingLei-NOAA> @hu5970 <https://github.com/hu5970>,
@MatthewMorris-NOAA <https://github.com/MatthewMorris-NOAA>,
@ManuelPondeca-NOAA <https://github.com/ManuelPondeca-NOAA> @GangZhao-NOAA
<https://github.com/GangZhao-NOAA>,
There is one suggestion from Guoqing ***@***.***
<https://github.com/guoqing-noaa>) -- "*I would suggest making
i_howv_in_3dda a tuning parameter in a GSI namelist*". Manuel and I
discussed on it, and Manuel pointed out that, if howv is added in anavinfo,
esp. added as state vector and control vector, howv would be analyzed, even
user sets "i_howv_3dda=0" and wants to turn it off. This would be a problem.
Hi @GangZhao-NOAA <https://github.com/GangZhao-NOAA> , thanks a lot for
the testing! Yes, you are right. I did not consider that we will also add
howv in the control vector section. So, in this situation, we will need to
have two different versions of the anavinfo files for howv runs and no-howv
runs respectively.
I think this PR should work without any running issues.
However, as for the treatment of i_howv_in_3dda, we have different
preferences. I would prefer putting i_howv_in_3dda as a namelist
parameter so as to avoid the following source code changes:
src/gsi/gsi_rfv3io_mod.f90
mpi_itype, call mpi_bcast(i_howv_3dda,...
src/gsi/rapidrefresh_cldsurf_mod.f90
Lines 451-459, 362-364 and 367
This is just a personal preference.
—
Reply to this email directly, view it on GitHub
<#614 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMWMXU6JCIBF4TBZSTDIBIDX4MKFPANCNFSM6AAAAAA35RZB5M>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
GangZhao-NOAA
requested review from
MatthewMorris-NOAA,
TingLei-NOAA and
guoqing-noaa
|
This PR has already gotten two approvals. I think it is enough for the review handing team to decide next step. Thanks! |
|
@GangZhao-NOAA Could you do regression tests on WCOSS2 and Hera for this PR? Thanks, Ming |
|
WCOSS2 is not in good shape for running jobs. It took for most of the day to finish a set of regression tests. Here are the regression tests results for this PR on Cactus: The results of failed test cases were checked and there are the reason of failures: Those are not fatal failure. We can think those 8 cases are passed. Now, the last case is "global_4denvar" and it crashed several times for both control runs and update runs. |
|
@hu5970 I followed your suggestions and re-compiled the GSI code on hera: first I compiled GSI code with develop branch (commit #ca19008 ) secondly I checked out the branch "feature/3drtma_howv (commit #f6031bd)", and recompiled GSI code. Then I started the regression tests on Hera. Here are the brief results, firstly I ran 9 regression tasks in a batch: There is one task, rfs_3denvar_glbens, which failed in the scalability test. Then I re-ran this task: Then the task "rrfs_3denvar_glbens" also succeeded. |
Adding code to analyze the siginificant wave heigh in GSI 3D Analysis, esp. for FV3-LAM model based DA, eg. RRFS-DA, RRFS-3DRTMA. (Also see the issue in EMC GSI github repository: #601
Adding I/O for Analysis of Significant Wave Height for 3DRTMA)
Description
Significant Wave Height (hereafter as SWH) is one of the standard products provided by the operational (2D)RTMA. To continuously provide the same products in 3DRTMA, the next-generation RTMA, some efforts in GSI code need to be made in order to analyze the SWH in 3D analysis of GSI.
The kernel subroutines to assimilate SWH in GSI (such as stphowv.f90, setuphowv.f90, inthowv.f90, gsi_howvOper.f90 and m_howvNode.f90) already had been added for (2D)RTMA years ago by Manuel Pondeca, so for this issue, the code work mainly focus on adding the I/O of SWH in background and analysis fields for 3DRTMA (esp. RRFS-based 3DRTMA), and some necessary modifications in background error, options, variables related to analysis of SWH, etc.
Modified code in GSI:
No dependencies are required for this change.
This PR is addressing the issue #601: Adding code to analyze the siginificant wave heigh in GSI 3D Analysis".
Fixes #601
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
[gang.zhao@clogin07:build] (feature/3drtma_howv)$ ctest -N
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
Test #1: global_3dvar
Test #2: global_4dvar
Test #3: global_4denvar
Test #4: hwrf_nmm_d2
Test #5: hwrf_nmm_d3
Test #6: rtma
Test #7: rrfs_3denvar_glbens
Test #8: netcdf_fv3_regional
Test #9: global_enkf
Total Tests: 9
Test #1: global_3dvar
[gang.zhao@clogin04:build] (feature/3drtma_howv)$ ctest -R global_3dvar
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
Start 1: global_3dvar
1/1 Test #1: global_3dvar ..................... Passed 1631.12 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 1631.14 sec
Test #2: global_4dvar
[gang.zhao@clogin09:build] (feature/3drtma_howv)$ ctest -R global_4dvar
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
Start 2: global_4dvar
1/1 Test #2: global_4dvar ..................... Passed 2462.19 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 2462.23 sec
Test #3: global_4denvar
[gang.zhao@clogin04:build] (feature/3drtma_howv)$ ctest -R global_4denvar
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
Start 3: global_4denvar
1/1 Test #3: global_4denvar ................... Passed 1922.43 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 1922.46 sec
Test #4: hwrf_nmm_d2
[gang.zhao@clogin09:build] (feature/3drtma_howv)$ ctest -R hwrf_nmm_d2
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
Start 4: hwrf_nmm_d2
1/1 Test #4: hwrf_nmm_d2 ...................... Passed 1214.10 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 1214.20 sec
Test #5: hwrf_nmm_d3
[gang.zhao@clogin09:build] (feature/3drtma_howv)$ ctest -R hwrf_nmm_d3
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
Start 5: hwrf_nmm_d3
1/1 Test #5: hwrf_nmm_d3 ...................... Passed 736.38 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 736.50 sec
Test #6: rtma
[gang.zhao@clogin05:build] (feature/3drtma_howv)$ ctest -R rtma
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
Start 6: rtma
1/1 Test #6: rtma ............................. Passed 1027.01 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 1027.01 sec
Test #7: rrfs_3denvar_glbens
[gang.zhao@clogin06:build] (feature/3drtma_howv)$ ctest -R rrfs_3denvar_glbens
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
Start 7: rrfs_3denvar_glbens
1/1 Test #7: rrfs_3denvar_glbens .............. Passed 484.69 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 484.70 sec
Test #8: netcdf_fv3_regional
[gang.zhao@clogin03:build] (feature/3drtma_howv)$ ctest -R netcdf_fv3_regional
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
Start 8: netcdf_fv3_regional
1/1 Test #8: netcdf_fv3_regional .............. Passed 483.08 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 483.11 sec
Test #9: global_enkf
[gang.zhao@clogin03:build] (feature/3drtma_howv)$ ctest -R global_enkf
Test project /lfs/h2/emc/da/save/gang.zhao/WorkDir/WaveHgt/develop/build
Start 9: global_enkf
1/1 Test #9: global_enkf ...................... Passed 488.50 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 488.57 sec
The modified GSI code passed the regression tests (all 9 tasks) on Hera and WCOSS2 (Cactus).
adding the analysis of howv only has very trial influences on the analyses of other variables. Here is the statistics of the differences of other variables (u/v/t/ps/q/t2m/q2m) from the runs of GSI without howv vs. with howv (from a testing case 2023-07-12_14:00:00 UTC in 3km North-American domain):
comparing two netcdf files: fcst_fv3lam_hyb_betas/INPUT/fv_core.res.tile1.nc fcst_fv3lam_nodata_noinfo/INPUT/fv_core.res.tile1.nc ...
Variable Group Count Sum AbsSum Min Max Range Mean StdDev
u / 602135550 3926.84 25760.8 -0.1026 0.485788 0.588388 6.52152e-06 0.00115817
v / 620166777 -4891.34 32582.5 -0.835774 0.268402 1.10418 -7.88714e-06 0.00197793
T / 155987083 178.048 6497.51 -0.0246582 0.0384064 0.0630646 1.14143e-06 0.000218737
delp / 19559676 -281.532 3008.29 -0.00292969 0.00219727 0.00512695 -1.43935e-05 0.000183727
comparing two netcdf files: fcst_fv3lam_hyb_betas/INPUT/fv_tracer.res.tile1.nc fcst_fv3lam_nodata_noinfo/INPUT/fv_tracer.res.tile1.nc ...
Variable Group Count Sum AbsSum Min Max Range Mean StdDev
sphum / 430707614 0.594287 2.77816 -2.6139e-05 3.1759e-05 5.7898e-05 1.37979e-09 8.03072e-08
comparing two netcdf files: fcst_fv3lam_hyb_betas/INPUT/sfc_data.nc fcst_fv3lam_nodata_noinfo/INPUT/sfc_data.nc ...
Variable Group Count Sum AbsSum Min Max Range Mean StdDev
t2m / 10665000 43.3899 135.095 -0.00152825 0.00686629 0.00839454 4.06844e-06 5.02866e-05
q2m / 10665000 0.0192553 0.124707 -3.1476e-06 1.77554e-05 2.0903e-05 1.80547e-09 5.89657e-08
It could be seen that the differences are trivial and ignorable.
The regression tests were done by following the instructions of "GSI Ctests (regression tests)" in GSI Wiki
The modified code had also been tested with a testing case 2023-07-12_14:00:00 UTC for 3km North-American domain
Here is a brief summary of the test results:
Checklist
DUE DATE for this PR is 10/5/2023. If this PR is not merged into
developby this date, the PR will be closed and returned to the developer.